![[レポート] AWS Nitro とは何かを理解する | Powering next-gen Amazon EC2: Deep dive on the Nitro System #CMP301 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2020/11/eyecatch_reinvent-2020-session-report.jpg)
[レポート] AWS Nitro とは何かを理解する | Powering next-gen Amazon EC2: Deep dive on the Nitro System #CMP301 #reinvent
コンバンハ、千葉（幸）です。
AWS re:Invent 2020 の残照を追うが如く、以下セッションを視聴したのでレポートにまとめます。
| 項目 | 値 |
|---|---|
| セッションタイトル | Powering next-gen Amazon EC2: Deep dive on the Nitro System |
| スピーカー | Abby Fuller, AWS Speaker |
| セッションレベル | Advanced - 300 |
| セッションID | CMP301 |
本エントリでは、以下の書き分けをします。
- 書き言葉：セッションの要約
- 話し言葉：筆者によるコメント
コメントでは、直接セッションで言及されていないことについても触れています。特に、出てくる技術用語の解説など、別のソースから引用している箇所が多くありますので御留意ください。
セッション概要
The AWS Nitro System, a rich collection of building block technologies that include AWS-built hardware offload and security components, is powering the next generation of Amazon EC2 instances with an ever-broadening selection of compute, storage, memory, and networking options. This session dives deep into the Nitro System, reviewing its design and architecture, exploring new innovations to the Nitro platform, and showing how it has made the seemingly impossible, possible.
機械翻訳の結果はこちら。
AWS Nitro Systemは、AWSが構築したハードウェアオフロードとセキュリティコンポーネントを含む豊富なビルディングブロック技術の集合体であり、コンピュート、ストレージ、メモリ、ネットワークのオプションがこれまで以上に幅広く選択できるようになり、次世代のAmazon EC2インスタンスを強力に後押ししています。このセッションでは、Nitroシステムを深く掘り下げ、その設計とアーキテクチャをレビューし、Nitroプラットフォームの新たなイノベーションを探り、不可能と思われていたことを可能にした方法を紹介します。
スピーカーはプリンシパルセキュリティエンジニアの方のため、例年のセッションと比べてセキュリティ面に関しての言及が多かったです。
Nitro とは何か？
Nitroとは
- 2017年11月にローンチ
- 2013年から開発されていた
- 専用ハードウェアとソフトウェア
- AWS 開発のカスタムハイパーバイザー
- 新たなインスタンスは Nitro を使用してローンチされている
Nitro の登場により、AWS 側でのより迅速なアップデートが可能になりました。
Nitro の 3 つのパーツ
Nitro カード
- VPC ネットワーキング
- Amazon EBS
- インスタンスストレージ
- システムコントローラー
Nitro カードの中の一つとして、カードや他のコンポーネントとの取りまとめを行う Nitro コントローラーが存在します。
Nitro セキュリティチップ
- マザーボードに統合されている
- ハードウェアリソースを防御
- ハードウェアの root of trust
root of trust とは「信頼の基点」と訳されます。以下サイトに詳しいです。
上記のサイトを参考にすると、信頼の基点とは「デバイスの信頼性を保証するための、ハードウェア/ソフトウェアコンポーネント」を指し、以下の機能を提供するとされます。
- ソフトウェアの完全性検証
- デバイス認証機能
- 暗号、認証、検証鍵の保護
信頼の基点はソフトウェアコンポーネントでもなり得ますが、Nitro ではハードウェアコンポーネントであるセキュリティチップがその役割を担っていることが分かりました。
Nitro ハイパーバイザー
- 軽量なハイパーバイザー
- メモリとCPUの割り当て
- ベアメタルのようなパフォーマンス
一般的にベアメタルサーバでは、ハイパーバイザーにリソースを割く必要がない分、そうでないサーバと比較してパフォーマンスが出やすいとされます。
Nitro ハイパーバイザーは、軽量なためにベアメタル同等のパフォーマンスが出るとのことです。
Nitro の重要項目
- 「ソフトウェアデバイスモデル（例えば Xen のような）」から「ソフトウェア定義されたハードウェアモデル」へ
- Amazon EC2 システムの変更はハードウェアイベントとしてモデル化されている
- NVMe や ENA のホットプラグ
- ACPI 電源状態の変更 など
- ハードウェアへのマイクロサービスモデルの拡張
- ENA、NVMeプロトコルは、革新することができる強化された API
- データの隠蔽とサービスの分解
- ソフトウェア要素もマイクロサービスであり、すべて動的にアップデート可能
- 大規模なアップデートでも仮想マシンのダウンタイムなし
それまでソフトウェアで実現してきたことをハードウェアにオフロードするというのは Nitro の重要な観点であると感じました。同時に、個々のコンポーネントを小さく（モノリスからマイクロへ）することにより、迅速なアップデートに対応させています。
セッションで触れられた内容ではありませんが、NVMe 、ENA という用語について確認しておきます。
NVMe とは
Wikipedia の記載を引用すると、以下の通りです。
NVM Express（NVMe）またはNon-Volatile Memory Host Controller Interface Specification（NVMHCIS）は、PCI Express（PCIe）バスを介して接続された不揮発性ストレージメディアにアクセスするためのオープンな論理デバイスインターフェイス仕様
ひとまずインタフェースの仕様であることは理解できました。
不揮発性メモリ（NVM）（あるいは不揮発性ストレージ）についての言及はこの後のセクションでも登場します。
ENAとは
ENA は Elastic Network Adapter の略で、Amazon が EC2 向けに開発した次世代ネットワークインタフェースです。
AWS Nitro のローンチより先行して 2016 年に発表されました。
インスタンスに ENA 用のドライバをインストールすることで拡張ネットワーキングを使用できるようになります。（現行世代のインスタンスでは標準でインストール済み）
Nitro のコンポーネントを深掘り
Nitro カード
- Nitro カード for VPC
- ENA コントローラー
- VPC データプレーン
- カプセル化やセキュリティグループ、帯域制限、ルーティング
- Nitro カード for Amazon EBS
- NVMe コントローラー
- Amazon EBS データプレーン
- 暗号化サポート、リモートストレージプロトコル NVMe
- Nitro カード for インスタンスストレージ
- NVMe コントローラー
- インスタンスストレージデータプレーン
- 転送中の暗号化、上限、ドライブのモニタリング
- Nitro カードコントローラー
- 受動的な API エンドポイントの提供
- Nitro カード、Nitro ハイパーバイザー、Nitro セキュリティチップのコーディネート
- ハードウェアのコントローラー
- root of trust
- 指標と証明の提供
- Nitro セキュリティチップ
- 詳細は次のセクションで
Nitro ハイパーバイザーによって仮想マシンがホストされますが、 EC2 インスタンスとして機能するためには EBS や VPC との関連づけが必要です。各種 Nitro カードによってそれらが実現されます。
Nitro カードの一つである Nitro コントローラーは API を受け取り、それをもとに各種カードのコーディネートを行います。
AWS カスタマーが発行した API リクエストは、（間にどのような処理が入るか分かりませんが）めぐりめぐって Nitro コントローラーへの API として到達するのだと想像しました。
Nitro セキュリティチップ
- 不揮発性ストレージへのすべてのI/Oを トラップ するカスタムマイクロコントローラー
- Nitro コントローラーから制御してシステムブートを保持可能
- 測定、検証、ファームウェアの更新などのための様々なモード
- すべてのハードウェア・インターフェースを監視
- シンプルなハードウェアベースの root of trust を提供
Nitro ハードウェアの root of trust
- 全ての不揮発性ストレージへの書き込みアクセスはハードウェアでブロックされる
- レガシーな要素がなく、Nitro カードへのオフロードによるシンプルさ
インスタンスが自身をホストするハードウェアの NVM に対して書き込みアクセスしようとしても、Nitro セキュリチップによってブロックされます。Nitro コントローラーだけが、セキュリティチップを通じてコントロールできます。
- Nitro コントローラーは root of trust（信頼の基点）
- コントローラーがプライベート SSD からブート
- さまざまなコンポーネントの整合性チェックを実施
- メインボードの起動
- セキュアチャネルと署名されたバイナリを介してすべてのコンポーネントにソフトウェアアップデートを適用
「メインボードの起動」プロセスについて深掘りされます。
メインボードの起動
- メインボードはファームウェアの更新（セキュリティチェック）ができない
- メインボードに電源が投入された際、Nitro コントローラーがファームウェアを検証している間はリセット状態に保たれる
- 検証が済んでからメインボードが次の段階に進む
- 次に、正常なハイパーバイザーを挿入するか、EBSボリュームからカスタマーAMIを起動する
メインボードの起動においても、 Nitro コントローラーによる制御が行われているということです。
boot customer AMI from EBS volumeが何を意味しているのかは正直理解できませんでした、、（ EBS Backed な AMI からインスタンスを立ち上げる……でしょうか）
Nitro はどうやってここまで来たか
仮想化の背景を簡単に
- 2006年に Xen と共に開始
- Xen によって同一ハードウェア上で複数の OS を稼働させることが可能に
- Xen では2つのタイプの仮想化があった
- PV (paravirtualization)
- HVM (hardware-assisted virtualization)
- PV（準仮想化） では、変更された OS でゲストが稼働する
- 明示的に仮想化をサポートしていないハードウェアでも動作する
- HVM（ハードウェア仮想マシン） では、ゲストは完全に仮想化され、OS に変更が加わらない
- ゲストはホストハードウェアへ素早いアクセスが可能
PV と HVM の比較については以下に記載があります。
KVM と Nitro
- Nitro によって KVM (Kernel-based Virtual Machine) ベースに切り替わった
- Nitro はカードとコントローラーを提供
- コントローラーはリソース（CPU、メモリ）の割り当ても行う
- Xen のDom0（ソフトウェアデバイスモデル）は、システムバス上のソフトウェア定義のハードウェアデバイスに置き換えられた
- Nitro コントローラーだけが AWS ネットワークにアクセスできる
- メインボードは AWS ネットワークにアクセス不可
- ハイパーバイザーはインスタンスの代わりにのみ実行できる
Dom0 について、Wikipedia では以下のように説明されています。
最初のゲストOSは、Xenの専門用語において「ドメイン 0 (dom0)」と呼ぶ。これは標準において、ハイパーバイザが起動する時に自動的に実行され、特別な管理特権と、全ての物理ハードウェアへの直接アクセスを受け持つ。システム管理者は、追加された全てのゲストOSに対して、dom0を通してログインすることができる。
Dom0自身もソフトウェアによって実現される仮想マシンの一つであり、他のゲストOSへのリソースの割り当てやハードウェアとのやり取りを担います。
用語集 Red Hat Enterprise Linux 5 | Red Hat Customer Portalより
Nitro ではそういった機能はハードウェア（Nitro カード）にオフロードされているため、 Dom0 を稼働させるためのリソースが不要になります。
- Nitro コントローラーが各種コンピューター（Nitro カード）を制御
- Nitro カードとゲスト OS（EC2インスタンス）が PCIe bus を通じてホットプラグ接続
- NVMe によりエミュレートされEC2インスタンス上で認識される
EBS ボリュームが VNMe デバイスとして認識される、という話は以下でも記述があります。
鳥瞰図はこちら。
この図だと Nitro コントローラーやカードも Nitro ハイパーバイザー上で稼働しているようにも見えますが、そんなことはありません。
あくまでインスタンスが Nitro ハイパーバイザー上で稼働し、それらのインスタンスと Nitro カード群が PCIe バスにより接続される、という考え方です。
こちらの絵を見るとよりイメージがつきやすいかと思います。
https://www.awsgeek.com/AWS-re-Invent-2020/The-Evolution-of-the-EC2-Host/より
Nitro によるセキュリティ上の利点
信頼と簡素化
- セキュアブート、暗号化された通信経路
- ハードウェア root of trust
- 継続的な暗号化された測定およびシステム検証の実施
- 従来のシステムよりも高いレベルの信頼性
- スタック全体の簡素化（カードへのオフロードによる）を通じた TCB （トラステッドコンピューティングベース）の最小化
ストレージ、ネットワーク、セキュリティという機能をソフトウェアでモノリシックに実現していたものを、個々の機能を各種カードにオフロードすることでシンプル化を実現している。それは迅速なアップデートを実現するだけでなくセキュリティの向上にもつながっている、と捉えました。
限定されたオペレーターのアクセス
- 一般的なハイパーバイザーでは 管理者は無制限のアクセスができるが、Nitro では限定されたオペレーター API を通じてのみアクセスできる
- オペレーターはカスタマーのデータにアクセスできず、承認されていない方法でシステムに変更を加えられない
- root ユーザーアクセスも SSH アクセスもできない
- 全てのアクセスはロギングが有効な状態で、認証/認可を通じて行われる
Dom0 がハードウェアに置き換えられて無くなったという話は先述の通りですが、使用するリソースが削減されただけでなく、「Dom0を通じたアクセスが不可能になった」というメリットもあります。
攻撃領域を限定するための専用ハードウェア
- 従来の仮想化では汎用的なサーバを使用しているために不要なコンポーネントが含まれ、攻撃対象を拡大することになる
- Nitro ではハイパーバイザーに必要なコンポーネントだけを持つ専用ハードウェアを使用することで攻撃対象を減らしている
- 攻撃対象が小さいということは潜在的なセキュリティ脆弱性の領域も小さいことを意味する
- 専用ハードウェアやソフトウェア（チップなど）に機能がオフロードされ、ハイパーバイザーは必要最小限に抑えられている
コントローラーとカード間のプライベートチャンネル
先ほど Nitro コントローラーとカード間での通信について触れましたが、両者の通信はプライベート経路に限定されています。
暗号化
- ハードウェアの加速によりパフォーマンスに影響を与えることなく以下の AES-256 の暗号化が可能となった
- インスタンスストレージ
- 全てのデータが暗号化される
- Amazon EBS
- アカウントレベルで暗号化の強制が可能
- ネットワーク
- N を持つインスタンスタイプ（M5nなど）同士の、（LBやTGWを経由しない）直接のトラフィック
- 同一 VPC、ピアリング経由、クロスリージョン
- すべて 100 Gb/s まで
- インスタンスストレージ
ここで述べられているのは以下ページの記載内容に対応しているようですが、ネットワークで「クロスリージョン」とされている記述がドキュメントと異なるのが少し気になるところです。
暗号化ハム
先ほどのスライドの右下に位置する唐突なハム。
なんだこれ？？
スピーカーの方は以下のように語っていました。（意訳）
- 今年のイベント用のアイコンセットを見たら用意されていた
- 何のためにあるのか知らないが含めざるを得なかった
- 抗うことができなかった
……？ ………なるほど??？
キー管理
- Amazon EBS
- ボリュームは独立したライフタイム/スナップショットを持つため、キーの管理は AWS KMS を介して行われる
- インスタンスストレージ
- インスタンス ライイフサイクルに応じ、ローカルで生成され、使用され、削除される
- Amazon VPC
- シードマテリアルは AWS KMS によって生成され管理される
- すべてのコンテキストにおいて、平文のデータキーは Nitro コンピューターによってのみキャッシュ/使用され、カスタマーのワークロードコプロセッサーから防御されている
受動的なコミュニケーション
- ハイパーバイザーは Nitro コントローラーからの指示を待つ
- すべての指示はプライベートチャネルを通じて送信される
- ハイパーバイザーからコントローラーに対して通信を開始することはない
- ハイパーバイザーはネットワークに接続しない
- Nitro コントローラーは外部のコントロールプレーンから指示を受け取る
- 暗号化および認証された API コールを基盤ネットワーク上でリッスンする
- 外部の方向にアウトバウンド接続を開始することはない
- これらのいずれかのレイヤからのアウトバウンド通信は 危殆化 としてみなされる
Nitro コントローラーは外部のコントロールプレーンから API 経由で指示を受け、セキュアな経路で Nitro ハイパーバイザーやカードに対して指示を行う。外部方向への通信はブロックされる。ということが分かりました。
[New!] Nitro Enclaves
- 分離されたコンピュート環境
- 永続ストレージなし、インタラクティブアクセスなし、外部ネットワーク接続なし
- すべての通信はセキュアなローカルチャネル（VSOCK）を通じて行われる
- 個人情報などの機密情報を扱うワークロードに適している
- AWS KMS との統合、暗号認証
Nitro Enclaves のセッションについてはこちらのレポートでまとまっていますのであわせてご参照ください。
まとめ
発表から3年以上が経ち、AWS Nitro は決して目新しいサービス（機能）ではなくなりました。それでありながら、普段 AWS カスタマーとして Amazon EC2 を利用する際には深く意識する機会が少ない領域です。
縁の下の力持ちとしてサービスを裏側から支える Nitro について意識するいいきっかけとなりました。EC2 を起動するたび、 Nitro について思いを馳せましょう。
（ Amazon EC2 を AWS Nitro システムのハードウェアが支えているように、 VPC のコンポーネントは Black foot や AWS Hyper plane というデバイス/システムによって支えられていますが、それはまた別の話ですね。）
Nitro についてはセッションは例年行われています。それらの内容は似通っている部分も多いのですが、少しずつ差異があります。レポートを見比べることによってより深く理解してみてはいかがでしょうか。
2019年。
2018年。
2018年と2019年の比較。
2017年。
以上、千葉（幸）がお送りしました。
![[Update] AWS Launches new version of Nitro System : Nitro v5 #reInvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_new-service.png)
![[レポート]ゼロ特権操作: データにアクセスせずにサービスを実行する #SEC327 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_session-report.png)
